Subject: HPR Route Preference Proposal

From: [email-masked]
Date: Mon, 31 Oct 94 11:39:24 EST

Responses to various concerns and Q's regarding the HPR route preference proposal recently sent to this
mailing list:

>After all, if the optimal route was HPR only it
>would have been chosen without this coercive method.

I disagree...the only method for building routes, including routes that have HPR-capable
nodes, is the existing TRS COS-based method.  There is not one COS, nor can a new COS even
be defined by the user, that will prefer an HPR TG or node over an ISR-only TG or node.
This is because what TRS must check is the ANR-capability field in the TG Descriptor CV.
TRS doesn't check TG descriptors (it checks the TG and node
Characteristics CVs only) when building routes for a COS.  Therefore, a
'noncoercive' method, meaning don't do anything, can only by chance choose an HPR route
if there exist ISR-only TGs with the same characteristics as the HPR TGs.

What network managers can do to give lower weights to HPR TGs is to manually
'doctor up' the TG characteristics fields so that they will have lower weights than
non HPR TGs.  I suspect that they'll also have to 'doctor up' the nonHPR TGs as
well, because when you look at any of the COS table rows (acceptable characteristics
ranges that equate to a given weight) the range limits - high and low - are fairly
wide.  So, merely modifying some characteristic field may not affect the weight of
a TG at all since it may still fall in the same weight range.  This method requires
much more manual definition than the proposed function, has zero flexibility (every
time an HPR node is added to a network this same process needs to be performed),
and in my opinion is much more 'coercive'.

>In addition, this
>coercive method can force all your session traffic over one path and
>have you lose the load balancing that is possible with alternate routes
>of different weights.

This method of preferring HPR TGs over nonHPR TGs is almost exactly like
the COS method APPN uses for preferring one particular path over another,
based on the desired COS of the user.  Although what you're saying here is
correct, any existing COS can potentially cause the same problem, as long as
there exists one TG or node with differing characteristics in the network.

If, for example, a path existed in a network that was more desireable for
the COS #INTER, and every user was using the #INTER COS to communicate and
had access to that path then that path would be built by TRS every time.  Same problem.
Since operators have managed to avoid load balancing problems with the
'coercive' COS method APPN uses, I believe they will manage to avoid load
balancing problems when adding the mechanism to allow users to prefer HPR,
as opposed to interactive or batch, paths as well.

What this proposed function does is give greater control to users and
network managers.  If they don't like the function they can simply turn
it off, by taking it out of the DEFINE_MODE statement.  They have control
over this added ability to prefer HPR paths or not, whereas the do-nothing
function gives them much little control over this capability.

>You are also requiring system definition
>everywhere instead of having the network properly designed in the first
>place and I think that is a mistake.

System definition is not REQUIRED anywhere.  This proposal is a simple
feature that users can prefer to use or not, based on their desire to
ensure HPR paths are selected for applications they run that find HPR
more desireable than ISR.  I suspect there are a great many that do.
Managers who have this desire will need to modify a DEFINE_MODE command,
while those who don't desire this preference capability do not have to
do a thing.

>I agree with Mark that this could direct traffic over routes
>that are non-optimal. Just because a 64K SDLC line is using HPR
>doesn't mean that it is suddenly faster than a 16M T/R that is
>not using HPR !

You're right, Dave....it's possible that an HPR path is not the
optimal path, that an ISR-only path may actually provide better
performance for two given LUs that may want to talk to each other.
But two things should also be considered here.  HPR is designed explicitly
for higher-speed, low error-rate links.  When migrating to HPR, it makes
sense to migrate it to the faster portions of the network first.  So, usually
although not always, ANR-capable TGs will either have equal or better
performance.

Secondly, many users that prefer HPR paths (maybe most) are not
as interested in the extra routing performance ANR provides as they are in the
dynamic path switch capabilities provided by HPR/RTP.  There are a boatload
of applications in the industry out there (banking, wall street, etc.) that
require sessions that stay up from beginning to end.  People who use these
applications will certainly want an HPR path to carry that session.  If the
entire network is HPR, no problem.  If ISR-only paths exist, it is a
problem.  The proposed function guarantees these users that if an HPR path
exists from their node to the destination node, an HPR path will definitely
be used.  Without this function, or a similar function, that guarantee can not
be made.

>Also - assuming the proposed change went ahead - it appears to be
>a bit of an all-or-nothing approach. What happens in the case of
>a segmented network (ie one partially converted to HPR protocols) ?
>If there is a route that is mostly HPR, but has one or more non-HPR
>segments in the middle, shouldn't the "HPR preferred" indicator
>allow this route to be chosen if there is no HPR-only route ?
>With the current manner in which an HPR route is calculated, the
>non-HPR TGs are given infinite weighting, so this route would be
>avoided. The subsequent route calculation failure would then result
>in no preferrence for HPR TGs even though this is what is indicated
>in the MODE.
>Have I missed something, or do you agree that this is a concern ?

No, you didn't miss anything with this point.  I think you're addressing the
biggest drawback to the proposal.  It requires an end-to-end HPR path.
Particularly, if either endpoint does not support the RTP tower, then the
HPR tree will come up with nothing but blanks.  But even in this worst case
scenario, what will happen is exactly what happens without the proposal.  HPR
'sub'-paths can still be created, but it will be strictly by chance.

I don't think this drawback can be overcome, without requiring much more complex
changes to TRS's route calculation method.  About the simplest way I know of was
the previous proposal to introduce two new COS's, #HPRINTR and #HPRBATC.  This
method didn't have this drawback, HPR sub-paths were preferred as well as
HPR end-to-end paths, since we monkeyed slightly with the actual route calculation
methodology TRS uses.  But this method is considered a little too messy.  If anyone
can think of a simpler method and also overcome the drawback you mentioned, I'm
all ears.

>I am uncomfortable with associating this attribute with the MODE.  I feel
>that it violates the traditional interpretation of the difference between
>MODEs and COSes.  The MODE was originally created in SNA to describe the
>characteristics of the end-to-end session.

The HPR_PREFERRED parameter is also a characteristic of the end-to-end
session.  If an HPR path doesn't exist end-to-end, the parameter doesn't
provide any extra benefit.

>As the
>architecture of record (page 3-13 under DEFINE_CLASS_OF_SERVICE) states "COS
>definitions are used to define the desired characteristics of session
>routes."  As a result of the evolution of SNA, and the need to support
>back-level application program interfaces which do not provide the ability
>o specify a COS explicitly, the DEFINE_MODE includes
>the name of a COS.  However this is the only piece of route related
>information present in the MODE definition.  All other attributes of a MODE
>definition apply only to the end-to-end characteristics of the
>communications.  Since a preference for HPR routes is clearly one of "the
>desired characteristics of session routes" it should be specified in the
>COS.

The benefit from adding this preference to modes is that it probably makes
it easier for users to use the capability.  There has been one concern raised
that this makes it more difficult for users to define their own COS, because a
new column has to now be considered (HPR preference).  Also, it allows users to
prefer HPR paths regardless of what COS they use, even for user-defined COS's.
After all, ANR routing capability has nothing to do with the physical characteristics
of a link or node, and it is these characteristics and not software functionality,
that are measured against the COS tables.

Regards,
Tim

---

From: Mark Cossack <[email-masked]>
Date: Mon, 31 Oct 1994 13:29:45 -0600 (CST)

Excerpts from mail: 31-Oct-94 HPR Route Preference Proposal
[email-masked] (8697)

> if there exist ISR-only TGs with the same characteristics as the HPR TGs.

You completely missed my point.  By saying "if the optimal route was HPR
only it would have been chosen" means just that - optimal - as is best -
as in least cost - as in better than ISR TGs.  So if networks are
correctly migrated to HPR, there is no need for the coercive method you
are proposing.

> >of EQUAL weights.

> as opposed to interactive or batch, paths as well.

If this method is so bad, then why are you essentially doing the same
thing with your method?  There is already a way to prefer a certain
route given a specific COS and you are now defining another way to do
the same thing that doubles your route calculation expense when there is
not an HPR path available.

> System definition is not REQUIRED anywhere.

It is required where you want to do have this new method of route
calculation.  So instead of getting the networks built correctly, you
force all the endpoints to change their mode definitions.

> This proposal is a simple

That assumes that all the APPN implementations change to this new method
and then all the network players get their implementations done and out
to the field.  The customer then gets to install a new version of
APPN/HPR and change all the systems mode definitions which now have this
new function.  This is FAR from simple and much worse than properly
migrating your network to include HPR links where you want to take
advantage of HPR's new capabilities.  I would certainly not recommend
this change for AS/400.

> Tim

Mark